重新整理 .net core 实践篇 |
您所在的位置:网站首页 › dump core是什么 › 重新整理 .net core 实践篇 |
前言
本文的上一篇为: https://www.cnblogs.com/aoximin/p/16861797.html 该文为dotnet-dump 和 procdump 的实战介绍一下。 正文现在很多情况下去抓取dotnet 运行的信息一般都是适用 procdump 或者 直接使用dotnet-dump 这个procdump 有什么用呢? 根据 ProcDump 帮助,下面是必须使用的开关: -M:当内存提交超过或等于指定值时触发核心转储文件生成 (MB) -n:退出前要写入的核心转储文件数 (默认值为 1) -s:连续几秒钟写入转储文件 (默认值为 10) -d:将诊断日志写入 Syslog -p:进程的 PID这个的好处就是有时候突然间内存升高,其实就是多了一个监控的作用。 我记得以前每次用dotnet-dump的时候,我让运维写了一个脚本,当内存到达多少或者cpu到达多少的时候执行一些dotnet-dump 这个命令。 我们知道一般抓取需要连续抓取,那么我们用上一篇的例子抓一下。 procdump -pgid 108232 -n 2 -c 50 -s 3上面就是说cpu到达50%并持续时间3秒,那么就执行抓取操作,一共抓取两次,相隔10秒。 这个procdump 抓取的内容在workdirection下面,也就是自己的工作目录下面。 那么抓取一次。 运行的时候一直在monitor,看到了吧。 然后执行慢查询: 这样就ok了。 然后用dotnet-dump 去解析就好了。 如果使用dotnet-dump 的话: 这个是安装: dotnet tool install -g dotnet-dump然后你也可以这么收集: 查看正在运行的dotnet core: dotnet-dump ps然后: dotnet-dump collect -p xxx根据进程号收集就好了。 但是这样只能手动,procdump 可以做到监听。 如果是偶发性的用procdump 比较好,比如不是,那么用dotnet-dump就好了。 然后dotnet-dump 分析的话,举个例子: dotnet-dump analyze /tmp/coredump.manual.1.108232然后其实和lldb 没有什么区别,其实lldb 更为强大而已,带调试功能和查看非托管的功能,而dotnet-dump 查看托管问题。 可以看到命令差不多。 把上篇文章的上半段内存问题给演示下: dumpheap -stat统计一下: 这个 string 很大,然后查看大对象: dumpheap -stat -min 85000大于8.5k string 有 365个。 查看一下对象堆,并且活跃的,可以理解为没有被GC标记的吧: dumpheap -mt 00007f4908c80f90 -min 85000 -live这里就有4个了。 那么查看其中一个就好。 95m差不吧。 然后看下其位置:gcroot -all 00007f48b6458178 这样就找到了代码的位置。 结该系列逐步补充,补的是一些排查技巧和一些原理,为什么这样抓取,为什么能抓到之类的,怎么排查更快之流。 持续更新。。。。。。。 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |